Hi Gil,
I will try to upload my files to SVN later today. After work :) Have been doing the profiling om my home PC.

Br,

//Burra

Hi Burra,
If you are not sure that your profiling-files are good, then you better not upload it yet to the repository. Please post here on the forum first your ./configure --... parameters and the output you get. Please also post your x264 executable and your gmon.out files.

By inspection of it looks as if threading is enabled.

In the post where you specifiy the steps you took, you omitted running make between steps 1 and 2. If you didn't compile (make) the code after using the ./configure script, it would not affect the x264 executable.

-gil

Hi,
this is how I did my 64bit bin and outputs.

http://pastebin.com/m1e71724f

hope the gmon.out file is ok

//Burra

Hi Burra,

Your configuration looks fine. I think you should disable the debugging option. It has no extra value for profiling, and can even affect the results.
Your compilation (make) looks fine. It actually looks even better than on my machine (which gets some warnings, mostly for possible array boundaries exceeding).

You didn't post your x264_64 executable, so I can't tell if the problem in occurs in your gmon.out or not. please post it too.

- gil

Hi Gil,
will post my 64 bit bin when I am back home. (Might need to open a ssh port to my desktop, so I can access files from work)

Have you started to see a possible route what function to HW accelerate first? There are some functions that often take >12% CPU in my runs.

x264_pixel_sad_16x16
x264_pixel_sad_8x8
x264_pixel_satd_8x4
get_ref

Should one try to implement the x264_pixel_sad_16x16 first to get going. Then one could learn by doing. If it works, start making more of x264_pixel functions. Finally end up making the complete x264_me_search_ref function in HW.

Do you have some ideas howto going about it?

//Burra

Hi,

I've noticed as well that some of the x264_pixel_sad_hxw (Sum of Absolute Differences) and x264_pixel_satd_hxw (Sum of Absolute Transformed Differences) are taking much of CPU relative execution time. These functions are mostly being called by x264_me_search_ref (me = motion estimation), and by x264_refine_subpel. The mc_chroma function (mc = motion compensation) is also very expensive (when decoding files with more than 1500 frames it becomes the most expensive.

I think that we should understand the relevant H.264 parts and the x264 code before choosing functions to be implemented in HW. I've been learning the H.264 baseline profile encoding basic and now I'm now getting acquainted to the x264 code (I suggest using doxygen on the Doxyfile supplied with the x264, enabling call graphs for anyone who wants to browse the code). The is no code documentation that I could find. If someone has found such documentation, please tell us.

Anyway, I think that before we begin HW implementation, we should decide what architecture to use, how to interface SW with HW, and how to conduct testing. I'm not sure if we should interface the OR1k simulator with verilog simulator (say Icarus) or maybe test the HW modules separately and then verify integration on test boards. I think we should open new topics on the board for discussing SW/HW partitioning and interfacing, and architecture issues.

I'll be absent until Sunday. I hope that by then we will have enough gmon.out files on the repository in order to choose functions for implementation.

- gil

Hi,
rebuilt my x264_64 and disabled the debug feature.

Gil this time I also had quite alot more of error messages during build.
http://pastebin.com/m4182f935

//Burra

These are warning and not error messages, which are similar to those I get. I guess (actually hope :) that these are the result of work in progress of the x264 development team. Since encoding is done successfully, I think we can ignore these warnings for now.

- gil

Hi Burra,

I looked at your gmon file, using your new x264_64 executable. In principle, gmon file must be tested using the original executable that used to create it, but I tried it anyway. It seems that you generate correct gmon files. However, you must pay attention to important issue. gmon.out file accumulates profiling results for each execution of the executable (x264_64 in this case). This includes even execution of ./x264_64 --help. It means that before executing x264 for profiling, the last gmon.out must be deleted. In the gmon.out file you posted earlier there are results for the Help function, as well as for some encoding functions. It suggests that this gmon.out file was created from multiple executions of the x264_64 executable. Please take care that the future gmon.out files you create are the result of single execution.

Please upload your x264_64 executable to /oc-h264-encoder/oc-h264-encoder/trunk/doc/x264_profiling/bin so that anyone who likes to create profiling files on 64-bit machines will use it, and so that anyone could read the gmon.out files generated using it.

- gil

I have added the profiling output to svn. This profiling was done for the higher side; HD video(1280x720) at 50fps, no of frames were ~600. I used the x264 binary from svn.

Do we have enough profiling information to start the discussion of implementation? I think, we all need to upload our profiling results.

-Gijo

Hi Gijo. Could you please upload the gmon.out profiling file? There are some tools (kprof for example), which need this file to work.

Gil,

gmon.out was renamed to mobcal_HD_1280x720_gmon.out and checked-in to svn under x264_profiling/gmon_files/. Are you looking for this or something else?

-Gijo

I'm having trouble playing .264 and .yuv (cif version) files on the vlc player.
version = 1.0.1 Goldeneye

The qcif version of the .yuv files play without the audio.
The cif version of the .yuv files looks all messed up and as if there is no sync at all.

For the .264 files, the vlc player attempts to play but it crashes. With the older version 0.9.x, the vlc player would crash.
With the new version 1.0.1, the application does not crash but the file does not play. It appears to start but then it closes.

Any ideas? I meant to ask this on the doom forum but there is a 5 day wait to post questions, after registering.

Thanks,
Guru

Hi Guru,



.yuv files does not embed audio. These files simulate raw video stream.



I have it too. I'm not sure how to play .yuv files of cif resolusion on vlc-player. I use application called 'videometer' to play .yuv files of cif and qcif resolution.



not a clue. works fine for me. vlc-player v.0.9.4 Grishenko on Ubuntu 8.10 Intrepid Ibex.

- gil

Thanks Gil. I am using UNR 9.04 Jaunty on a Atom N270 with 2GB RAM
That's correct, YUV is just video.

I downloaded the VLC player for Windows and the behavior was identical. The YUV(qcif version) files played but the cif versions and the x264 versions did not.

Not sure how to resolve this. Will check it out on the Doom9 forum.
Thanks again.

Guru